Skip to content

Conversation

@mkurz
Copy link
Contributor

@mkurz mkurz commented Oct 4, 2025

User description

💥 What does this PR do?

I am running Linux on a MacBook Pro M1 via https://asahi-alarm.org/.
The architecture of this machine is identified as aarch64 in Java (and in general).
When selenium tries to start selenium manager it fails because it tries to execute the x86-64 binary, which of course does not work on an aarch64 system.

🔧 Implementation Notes

Just also checking for aarch64.. Easy.

$ uname -a
Linux mkurz-macbook-pro 6.16.4-asahi-2-1-ARCH #1 SMP PREEMPT_DYNAMIC Tue, 02 Sep 2025 08:56:47 +0000 aarch64 GNU/Linux
$ uname -m
aarch64
$ jshell
|  Welcome to JShell -- Version 17.0.16
|  For an introduction type: /help intro

jshell> System.getProperty("os.arch")
$1 ==> "aarch64"
Screenshot_20251004_094212_2

🔄 Types of changes

  • Bug fix (backwards compatible)

PR Type

Bug fix


Description

  • Add support for detecting aarch64 architecture on Linux systems

  • Fix Selenium Manager binary selection for ARM-based Linux platforms

  • Improve error handling for unsupported ARM architectures


Diagram Walkthrough

flowchart LR
  A["System Architecture Check"] --> B["os.arch Property"]
  B --> C["ARM Detection Logic"]
  C --> D["aarch64 Support Added"]
  D --> E["WebDriverException Thrown"]
Loading

File Walkthrough

Relevant files
Bug fix
SeleniumManager.java
Add aarch64 architecture detection support                             

java/src/org/openqa/selenium/manager/SeleniumManager.java

  • Extended ARM architecture detection to include aarch64
  • Modified conditional check in getBinary() method
  • Maintains existing error handling for unsupported ARM platforms
+2/-1     

@CLAassistant
Copy link

CLAassistant commented Oct 4, 2025

CLA assistant check
All committers have signed the CLA.

@selenium-ci selenium-ci added the C-java Java Bindings label Oct 4, 2025
@qodo-merge-pro
Copy link
Contributor

qodo-merge-pro bot commented Oct 4, 2025

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢
No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🎫 No ticket provided
  • Create ticket/issue
Codebase Duplication Compliance
Codebase context is not defined

Follow the guide to enable codebase context checks.

Custom Compliance
No custom compliance provided

Follow the guide to enable custom compliance check.

  • Update
Compliance status legend 🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

@qodo-merge-pro
Copy link
Contributor

qodo-merge-pro bot commented Oct 4, 2025

PR Code Suggestions ✨

Explore these optional code suggestions:

CategorySuggestion                                                                                                                                    Impact
General
Improve architecture detection for robustness

Improve the robustness of the OS architecture check by storing os.arch in a
variable, converting it to lowercase, and using startsWith() instead of
contains() for matching.

java/src/org/openqa/selenium/manager/SeleniumManager.java [203-206]

-if (System.getProperty("os.arch").contains("arm")
-    || System.getProperty("os.arch").contains("aarch64")) {
+String osArch = System.getProperty("os.arch").toLowerCase();
+if (osArch.startsWith("arm") || osArch.startsWith("aarch")) {
   throw new WebDriverException("Linux ARM is not supported by Selenium Manager");
 }

[To ensure code accuracy, apply this suggestion manually]

Suggestion importance[1-10]: 6

__

Why: The suggestion improves code robustness and readability by using a local variable, converting to lowercase, and using startsWith() for a more precise architecture check.

Low
  • Update

@mkurz
Copy link
Contributor Author

mkurz commented Oct 5, 2025

Seems like the failing test times out.
This has nothing to do with my change.

@shbenzer shbenzer merged commit 4db2c56 into SeleniumHQ:trunk Oct 5, 2025
36 checks passed
@shbenzer
Copy link
Contributor

shbenzer commented Oct 5, 2025

This is a good addition - thank you @mkurz !

@mkurz mkurz deleted the os.arch_aarch64 branch October 5, 2025 19:51
@cgoldberg
Copy link
Member

Hopefully we will be supporting Linux and Windows on ARM soon, and we can update the platform detection code.

@mkurz
Copy link
Contributor Author

mkurz commented Oct 6, 2025

I am using and maintaining Asahi Arch Linux ARM, which is just a thin layer on top of Arch Linux ARM, and I can build and run selenium manager from you repo without any problems.
There is even an selenium-manager AUR ("Arch User Repository") which provides the selenium-manger package , which people can easily install with yay -S selenium-manager: https://github.com/archlinux/aur/blob/selenium-manager/PKGBUILD As you see it's just compiling what you provide in the repo (though a bit outdated version 4.30 as of today).

So regarding selenium manager I think all you have to do is build it for the aarch64 architecture and bundle it just like the x86-64 binary. You can do that easily nowadays with an arm GitHub actions runner, all you have to do is use runs-on: ubuntu-24.04-arm (see the -arm suffix): https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/

geckodriver can also be build for aarch64 easily, there is also an AUR for it: https://gitlab.archlinux.org/archlinux/packaging/packages/geckodriver/-/blob/main/PKGBUILD?ref_type=heads
You could build that too in a GitHub actions arm runner, or you could even use the precompiled package from Arch Linux ARM: https://eu.mirror.archlinuxarm.org/aarch64/extra/ (search for geckodriver on that page, you would need to unpack it and copy over the binary.

For the chromiumdriver it's similiar, either you compile chromium yourself (which takes quite a while...) or you use the precompiled binaries from the chromium package again (https://eu.mirror.archlinuxarm.org/aarch64/extra/). (currently chromium is totally outdated in Arch Linux ARM because they have a problem in the build setup).

@cgoldberg
Copy link
Member

We already have PRs open for building Selenium Manager on ARM64 for Linux and Windows. However, we have no intention of publishing our own geckodriver/chromedriver builds. (Mozilla already publishes geckodriver for ARM anyway).

@yezhov
Copy link

yezhov commented Oct 27, 2025

It seems this change ruined the workflow when you run tests inside a Docker container under macOS that worked perfectly fine on 4.36.0. Now it throws error:

org.openqa.selenium.remote.NoSuchDriverException: Unable to obtain: chromedriver, error Unable to obtain Selenium Manager Binary
2025-10-27T19:43:53.001579965Z 	at org.openqa.selenium.remote.service.DriverFinder.getBinaryPaths(DriverFinder.java:124)
2025-10-27T19:43:53.001580923Z 	at org.openqa.selenium.remote.service.DriverFinder.getDriverPath(DriverFinder.java:55)
2025-10-27T19:43:53.001581840Z 	at org.openqa.selenium.chrome.ChromeDriver.generateExecutor(ChromeDriver.java:99)
2025-10-27T19:43:53.001582715Z 	at org.openqa.selenium.chrome.ChromeDriver.<init>(ChromeDriver.java:88)
2025-10-27T19:43:53.001583590Z 	at org.openqa.selenium.chrome.ChromeDriver.<init>(ChromeDriver.java:83)
2025-10-27T19:43:53.001584382Z 	at org.openqa.selenium.chrome.ChromeDriver.<init>(ChromeDriver.java:72)
2025-10-27T19:43:53.001585173Z 	at com.bcdme.DriverFactory.initDriver(DriverFactory.java:41)
2025-10-27T19:43:53.001585923Z 	at com.bcdme.BaseTest.setup(BaseTest.java:30)
2025-10-27T19:43:53.001586715Z 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
2025-10-27T19:43:53.001587590Z 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
2025-10-27T19:43:53.001588465Z 	at org.testng.internal.invokers.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:141)
2025-10-27T19:43:53.001589340Z 	at org.testng.internal.invokers.MethodInvocationHelper.invokeMethodConsideringTimeout(MethodInvocationHelper.java:71)
2025-10-27T19:43:53.001590298Z 	at org.testng.internal.invokers.ConfigInvoker.invokeConfigurationMethod(ConfigInvoker.java:400)
2025-10-27T19:43:53.001591132Z 	at org.testng.internal.invokers.ConfigInvoker.invokeConfigurations(ConfigInvoker.java:333)
2025-10-27T19:43:53.001591923Z 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:358)
2025-10-27T19:43:53.001592632Z 	at org.testng.SuiteRunner.run(SuiteRunner.java:312)
2025-10-27T19:43:53.001593382Z 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
2025-10-27T19:43:53.001594132Z 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:95)
2025-10-27T19:43:53.001594840Z 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1274)
2025-10-27T19:43:53.001595590Z 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1208)
2025-10-27T19:43:53.001596340Z 	at org.testng.TestNG.runSuites(TestNG.java:1112)
2025-10-27T19:43:53.001597757Z 	at org.testng.TestNG.run(TestNG.java:1079)
2025-10-27T19:43:53.001598465Z 	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:308)
2025-10-27T19:43:53.001599257Z 	at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:71)
2025-10-27T19:43:53.001602590Z 	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:113)
2025-10-27T19:43:53.001603382Z 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
2025-10-27T19:43:53.001604132Z 	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
2025-10-27T19:43:53.001604882Z 	at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
2025-10-27T19:43:53.001605632Z 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
2025-10-27T19:43:53.001606382Z Caused by: org.openqa.selenium.WebDriverException: Unable to obtain Selenium Manager Binary
2025-10-27T19:43:53.001607215Z 	at org.openqa.selenium.manager.SeleniumManager.getBinary(SeleniumManager.java:229)
2025-10-27T19:43:53.001607965Z 	at org.openqa.selenium.manager.SeleniumManager.getBinaryPaths(SeleniumManager.java:275)
2025-10-27T19:43:53.001608798Z 	at org.openqa.selenium.remote.service.DriverFinder.getBinaryPaths(DriverFinder.java:104)
2025-10-27T19:43:53.001609548Z 	... 28 more
2025-10-27T19:43:53.001610215Z Caused by: org.openqa.selenium.WebDriverException: Linux ARM is not supported by Selenium Manager
2025-10-27T19:43:53.001611048Z Build info: version: '4.38.0', revision: '6b412e825c*'
2025-10-27T19:43:53.001611757Z System info: os.name: 'Linux', os.arch: 'aarch64', os.version: '6.10.14-linuxkit', java.version: '21.0.8'
2025-10-27T19:43:53.001612632Z Driver info: driver.version: ChromeDriver
2025-10-27T19:43:53.001613298Z 	at org.openqa.selenium.manager.SeleniumManager.getBinary(SeleniumManager.java:205)
2025-10-27T19:43:53.001614090Z 	... 30 more
2025-10-27T19:43:53.001614757Z 

@cgoldberg
Copy link
Member

cgoldberg commented Oct 27, 2025

@yezhov

That error should only be thrown if you are running Selenium Manager on a Linux system running arm64/aarch64.

But our platform detection logic is sort of complex...

Can you verify the configuration you are running?

It looks like:

  • You have a macOS host running on Apple Silicon?
  • You are running Selenium Grid on Linux in a Docker container?
  • Your code is running on the macOS host using a Remote WebDriver to connect to the Grid server?

Is that all correct?

Is your Docker container x86 or ARM?

If it is an ARM container, I'm a little confused how it used to work at all, since Selenium Manager doesn't run on that platform.

Can you open a new issue for this so we can track it?

@yezhov
Copy link

yezhov commented Oct 27, 2025

@cgoldberg,
The host is a MacBook Pro with macOS running on Apple Silicon (M2). A Docker container was created from a custom Docker image based on the Alpine Linux base image (aarch64) with all required packages like openjdk, chromium-chromedriver, maven, etc., installed. The local repo with tests is attached to the container via the "docker run -v" command, so the tests are started through the "mvn clean test" command and technically running in the Linux container environment. The host just initiated the whole process via the docker run command. There are no Selenium Grid or Remote WebDriver in this workflow. Prior to 4.37.0 with this adjustment, everything worked fine.

UPD: created #16520

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants